PEP 724: Stricter TypeGuard #3266
Conversation
…m/rchiodo/peps into rchiodo/pep-722-strictertypeguard
…m/rchiodo/peps into rchiodo/pep-722-strictertypeguard
Co-authored-by: Erik De Bonte <[email protected]>
Co-authored-by: Erik De Bonte <[email protected]>
Co-authored-by: Erik De Bonte <[email protected]>
Co-authored-by: Erik De Bonte <[email protected]>
Co-authored-by: Erik De Bonte <[email protected]>
…m/rchiodo/peps into rchiodo/pep-722-strictertypeguard
Co-authored-by: Erik De Bonte <[email protected]>
Co-authored-by: Erik De Bonte <[email protected]>
Update after Erik's feedback
…o rchiodo/pep-722
Reference intersection and negation docs
Fix lint
|
@AA-Turner you previously requested changes, please take another look. |
# Conflicts: # .github/CODEOWNERS
peps/pep-0724.rst
Outdated
| Given a ``TypeGuard`` and a calling function like so: | ||
|
|
||
| .. code-block:: python | ||
|
|
||
| def guard(x: P) -> TypeGuard[R]: ... | ||
|
|
||
| def func1(val: A): | ||
| if guard(val): | ||
| reveal_type(val) # NP | ||
| else: | ||
| reveal_type(val) # NN | ||
|
|
||
| Each use of a ``TypeGuard`` involves five types: | ||
|
|
||
| * P = ``TypeGuard`` parameter type | ||
| * R = ``TypeGuard`` return type | ||
| * A = Argument type (pre-narrowed) | ||
| * NP = Narrowed type (positive) | ||
| * NN = Narrowed type (negative) |
There was a problem hiding this comment.
This introduction to the Specification seems a bit odd / doesn't flow very well -- you start with "Given a function" and then in the next paragraph define a series of types with no reference or connection to the previous paragraph.
There was a problem hiding this comment.
I'm sorry but I'm not sure which parts aren't referencing each other. Did you mean the Kangaroo | Koala example? Or the reference to the different types : 'P, R, A, NP, NN'
There was a problem hiding this comment.
Did the update clarify this at all?
peps/pep-0724.rst
Outdated
| Intersection of types and type negation are not defined and are left up to the | ||
| type checker to decide on how to implement. Future extensions to the type | ||
| system may define this behavior though. |
There was a problem hiding this comment.
I was initially a little confused here, as this PEP doesn't propose Intersection[] or Negate[], but then I realised you probably mean achieving an intersection by using multiple type guards -- would it be worth adding a line of disambiguation?
There was a problem hiding this comment.
No, it doesn't mean achieving an intersection using multiple type guards. It means that strict type guards use intersection to define what they return. The return type of a strict type guard is the intersection of the input type (A) and the return type (R). This intersection isn't defined in Python yet.
There was a problem hiding this comment.
Pyright has its own implementation of this intersection at the moment.
Co-authored-by: Adam Turner <[email protected]>
Co-authored-by: Adam Turner <[email protected]>
Co-authored-by: Adam Turner <[email protected]>
This PEP modifies
TypeGuardso that the negative (false return value) can allow further narrowing in type checkers. It's based on a comment here:python/typing#1013 (comment)
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approvalAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--3266.org.readthedocs.build/pep-0724/